1. Field of the Invention
The present invention relates to a system and method for providing a private and secure transaction environment.
2. Description of the Related Art
Basic financial transactions including buy and sell transactions and withdraw and deposit transactions, have always required security to protect the account holder, the financial institution where the account resides, and a party at the point of sale from identity theft and fraudulent transactions. Due to widespread use of computer networks and electronic commerce as a new medium to perform transactions, new requirements to maintain validity and integrity of financial transactions are arising. There are companies violating consumer privacy by gathering, sorting, researching and selling for profit personal information about consumers acquired during financial transactions. It would be advantageous to provide an efficient system and method to protect customers' privacy during financial transactions. Another new requirement is associated with the fact that hackers and intruders may get illegal access to the computer network and compromise financial transactions. This aspect of transaction security is addressed in U.S. Pat. No. 6,092,202 to Veil et al.
Throughout the history of financial transactions, privacy and security have been addressed using the best contemporary technologies. Since the onset of the computer network era, computer power, relational databases, software environments and communication lines have been used by financial institutions for security and privacy functions. Banks, then credit card companies and eventually brokerage companies and other financial institutions have used computer systems to perform authentication, authorization and accounting, referred to as AAA, at their back offices during financial transactions.
Due to weaknesses in the authentication stage in financial transactions with credit cards, consumers have suffered significant losses. The authentication stage is based on a party at the point of sale who compares human signatures visually on a card (if there is any) and on a selling slip. This operation is error prone when identifying faked signatures in fraudulent actions. Also, if an account holder loses an unsigned credit card, it is easy to fake signatures as one can place any signature on a card before requesting a financial transaction. Another typical malfunction at the authentication stage of credit card transactions occurs when someone gets a credit card account number and a copy of the card owner's signature. This enables fraud even with non-stolen credit cards. Another example in which financial institutions incur losses arises when account holders change their minds after concluding a financial transaction. An account holder can repudiate the financial transaction by claiming that somebody acted in his or her place.
These examples show that there is a real and substantial need for improvements in financial transaction architectures at the authentication stage. Mistakes in authenticating fraudulent actors are often followed by successful authorization and accounting sessions at financial institution back offices, illustrating another weakness of the prior art financial transaction architecture. This occurs because the authorization and accounting stages are de-coupled from the actual account holder, while the authentication stages are de-coupled from financial institution back office computers.
Though credit cards have been used as a financial transaction instrument since the beginning of electronic commerce, there are a number of issues in the electronic commerce architecture that have become apparent. For instance, credit card data, a social security number, a card holder name, a phone number, an address etc., while transferred through the Internet, are not absolutely secure and can fall into the “wrong hands” due to communication channel leaks. It is obvious that while the high speed data flow through the Internet or other communication channels is a big advantage for financial transactions, insufficient data security makes it highly desirable to alter the financial transaction architecture to avoid potential data leaks.
Another issue jeopardizing financial transactions in electronic commerce is weakness of the authorization stage in credit card transactions. Neither the authorization stage nor the accounting stage is actively controlled and timed by the account holders. A number of fraudulent sell transactions may happen before the account holder regains control on his/her account after it has been breached. U.S. Pat. No. 5,485,510 to Colbert and U.S. Pat. No. 6,052,675 to Checchio disclose attempts to improve the authorization stage of financial transactions in order to enhance security. The Colbert patent proposed to alter financial transactions by authorizing an account holder before he/she applies to a merchant (a vendor). Information supplied to the back office includes a credit card account number, a secret PIN and information specific to the merchant and the financial transaction (including at least, a merchant ID number and a transaction amount). Then the merchant is given only the authorization code, while the card number and the PIN remain unknown to the merchant. A similar architecture is offered in the Checchio patent, except a merchant does not get any authorization code, but rather a credit card account number. Since the financial transaction is pre-authorized in this case, a merchant sends into the back office a credit card account number and merchant and financial transaction specific information, which are compared with data given by the account holder during the pre-authorization stage. Use of a lost or stolen card is prevented in the Checchio system using a secret PIN.
Though both Colbert and Checchio improve security against fraudulent usage of credit cards for certain types of transactions, there are limitations to be addressed. Both patents are centered on phone lines, when communicating to financial institution back offices. Frequent usage of a pair of static numbers (account numbers and PINs) over phone lines is insecure due to leaks at the line entries and on the lines themselves. This insecure communication line issue gets aggravated, if one would like to replace phone lines by wireless or the Internet communication lines. Another weakness common to both patents is lack of technology enabling the back office to handle the proposed architectural changes for large numbers of financial transactions. Financial transaction architectures ought to cover account holders, financial institutions and a party at the point of sale in a mutually dependent way. Both prior art approaches require knowledge of a party at the point of sale and other financial transaction specifics prior to the authorization stage. This requirement for authorization is an additional limitation in both Colbert and Checchio, narrowing down the types of possible financial transactions and the locations from which they can be performed.
There is a public concern that financial transactions with credit cards in electronic commerce channels and in other traditional channels could lead to personal information about the consumer being accessed, monitored, tracked, stolen and fraudulently used or sold for profit without the consumers' approval. Privacy related problems arc exacerbated with the advanced Internet related technologies due to the ease with which information can be collected, processed and combined with other information.
It is not only financial transactions with credit cards that raise numerous privacy issues. For example, an account holder would not always like a bank teller during standard withdraw and deposit transactions at a bank to have access to his/her personal information file. It would be beneficial if an account holder could decide whether this privilege should be given to the bank teller. More often than not, withdraw and deposit transactions at a bank require an account holder to reveal identification documents This requirement to reveal personal identification documents is a privacy related inconvenience justified by the current authentication process for such financial transactions.
FIG. 1A illustrates a block diagram of a conventional system for performing withdraw and deposit transactions. In order to perform financial transactions, a legal adult 101 (or a legal business) sets up an account with a financial institution. Typically, a personal information profile 102 is disclosed to the financial institution during the account application process 103. At step 104, the financial institution, which permitted an account opening, creates a personal log file in the financial institution back office, establishes a withdraw and deposit mechanism, and issues personal checks and cards. Then the account holder can perform deposit 105 or withdraw 106 transactions. Typical deposit transactions to a bank or a brokerage house 107 are made either with a personalized deposit slip 109 or a personal check, disclosing a name and account number. Another way of obtaining deposits used by insurance 117 and credit card companies 115, is to receive payments for account statements 119 from an account holder. Checks 110, debit cards 112 or Graphical User Interfaces (GUI) over the Internet 113 are used by account holders for withdraw transactions with a bank or a brokerage house 108. The credit card 116 is a typical withdraw mechanism for credit card companies (including banks like Visa and Master Card and other types of financial institutions, like American Express). Another withdraw mechanism is used by account holders with insurance companies 118. A request for payment 120 is to be made in accordance with the insurance policy.
There are deficiencies in the deposit and withdraw transaction system described above related to privacy and security of the account holder and the financial institution, including the following:
1) Direct and urgent deposit transactions can be hindered, if the account holder is located far away from the bank and its branches where the account resides. It should be possible to deposit to one's account via other financial institutions, without disclosing personal information at intermediate service levels in other financial institutions.
2) During depositing, bank tellers get access to the personal information of the account holder. There are two issues here. Firstly, a teller can make mistakes altering personal and account balance information without any immediate back office computer and database control. In other words, each deposit transaction has a probability of mistakes, hurting the bank and the account holder. Secondly, the account holder may not like a bank teller to have access to his/her personal information file during a direct deposit transaction. At this stage it would be beneficial, if the account holder could decide by himself/herself whether this privilege should be given to the bank teller.
3) Insufficient theft and fraud protection during withdrawal transactions with checks, credit, charge and debit cards or during electronic commerce financial transactions.
4) Personal information is not protected and often intentionally or unintentionally misused by a party at the point of sale or bank tellers during withdrawal transactions.
FIG. 1B illustrates a block diagram of a conventional system for performing buy and sell transactions. Once account holder 121, has made a buying decision 122 and applied to a party at the point of sale, the actual selling transaction is enabled through cash 124, credit cards 116, debit cards 112, checks 110 or electronic commerce 125. Though cash is handy for low value financial transactions, it is usually impractical for the bulk of financial transactions due to low cash amounts on hand. All other financial transaction instruments except cash, such as credit cards 116, debit cards 112, electronic commerce 125 and checks 110 lead to either complete or partial disclosure of personal information 127, and are therefore prone to misuse and fraudulent actions 128.
FIG. 2 illustrates a block diagram of a conventional system and method for performing authentication, authorization and accounting sessions during buy/sell transactions with a credit card, a charge card or a debit card. As illustrated in FIG. 1B and FIG. 2, once account holder 121 has made a buying decision 122 and applied to a party at the point of sale, a point-of-sale (POS) device scans static information on a credit card and sends an authorization request to the financial institution back office, specifying a price (money transaction amount), to perform a withdraw transaction 205. The back office computer checks whether there is enough money in the database under this account and if yes, then if the card is not marked in the database as lost, stolen or fraudulently used, authorizes the withdraw transaction 206, sending an authorization code to the point of sale POS device. Steps 205 and 206 constitute the authorization stage 201 of the financial transaction. It is worthwhile to note that in the conventional financial transaction system with credit/debit cards, the authorization stage is performed prior to the authentication and the accounting stages of the financial transaction.
Once the transaction authorization is sent to a party at the point of sale 206, the first accounting step 202 is performed. The account involved in the transaction is left with a locked sum of money to assure a payment to a party at the point of sale 207. The payment is made after deduction of the transaction fee to the card issuing bank and the discount rate fee to the acquiring bank or an independent sales organization, which provided merchant status to a party at the point of sale. Once step 207 is completed, the back office is ready for another transaction of the same account holder, provided the requested spending limit is not exceeded.
Then if the credit card is signed, the signatures on the selling draft and on the card are visually compared by a party at the point of sale for off line financial transactions 208. If the card is not signed, identification documents are requested from account holder 209. Steps 208 and 209 are components of the authentication stage of financial transaction 203 for the conventional off line financial transaction system. It can be noted here that the signature comparison step 208 is skipped by the conventional electronic commerce on line financial transaction system based on credit/debit card usage. Such electronic commerce systems enforce step 209, requiring wider disclosure, than in the case of an off line financial transaction, of personal information about the account holder. Then the final step of the accounting stage 204 is performed. Step 210 includes the following: a party at the point of sale sends the selling draft inside the selling batch after trade hours to the acquiring hank (or an independent sales organization). The acquiring bank re-routes the relevant part of the batch to the card issuing bank, which unlocks the payment and transfers it to a merchant account after deductions, specified in the merchant's agreement. Then in a few days, the money is placed into a merchant account.
The conventional financial transaction architecture based on credit or debit cards and shown in FIG. 2 has a number of weaknesses, which the present invention addresses, including the following:
1) The authentication stage is de-coupled from the back office CPU and dB, making it subjective, embarrassing, and error and fraud prone.
2) The authorization stage is de-coupled from account holder for both on and off line financial transactions, making it especially dangerous for on line financial transactions (for example, due to on line financial transaction latency, a number of unauthorized financial transactions may happen before the account holder regains control on the account).
3) Personal information leaks are possible on the Internet communication lines during electronic commerce sessions (browsing technology, TCP/IP protocols, PKI, SSL and other Internet technologies do not guarantee sufficient financial transaction security).
4) The accounting stage is de-coupled from the account holder, potentially causing inconvenience during a series of buy and sell financial transactions.
5) A party at the point of sale may collect and analyze personal information about the account holder, and market and sell the information for profit. This leaves the public at large unaware of the privacy and confidentiality status of the data.
Present on line and off line financial transaction architectures have substantial security and privacy deficiencies at the authentication, authorization and accounting stages. It would be highly desirable to provide an improved system and method wherein consumers can perform financial transactions with financial institutions without privacy and security concerns. The present invention addresses these problems.